The standard specifications for operation of Ethernet OAM circuits, and particularly those conforming to IEEE 802.1ag and ITU-T Y.1731, include a check for connectivity between two management endpoints (MEPs) in a management domain (MD). The management endpoints perform the check by means of the periodic transmission of connectivity check messages (CCMs) to each other. Both endpoints determine whether they have received a valid CCM within a prescribed time. The period, i.e. the interval between CCM transmissions, can be, under current specifications, any one of eight values starting from 3.3 ms up to 10 minutes. The period may be configured, i.e. selected for each connection. A connectivity error is reported by an endpoint when a CCM has not been received from the end point's partner within a set multiple (presently 3.5) of the CCM transmission interval. Thus at the fastest CCM rate (3.3 ms) an error will be reported when a message from the partner is not received within 3.5×3.3=11.55 ms.
There can be a multiplicity of operational levels at which a management point (MP) in general and a management endpoint (MEP) in particular can operate (currently 8) and the operational level typically defines the range of the monitored connection, higher numbers indicating the longer ranges.
CCM messages can also detect errors in configuration of the network path. These errors are referred to as ‘cross connect errors’ and ‘remote MEP errors’. Cross connect errors occur when a receiver does not recognise the domain. The domain is defined in a field in the CCM packet called a maintenance domain ID (MAID). They may also occur if the CFM level of the received CCM packet is lower than expected. Remote MEP errors occur if the receiver does not recognise the identity of the transmitter (defined in a field called the MEPID) or if the detected MEPID is its own MEPID, indicating that a packet was looped back on itself.
The performance of the network can be measured according to standards such as ITU Y.1731. This standard defines techniques to measure frame loss, frame delay and frame delay variation.
Frame loss can be measured in one of two ways. It can be measured simultaneously at both ends of a link (a dual-ended measurement) and proactively using CCM messages. Alternatively, it can be measured at one end of the link (a single-ended measurement) and on demand using a ‘loss measurement message’ (LMM) and a ‘loss measurement response’ (LMR). The originator sends an LMM, and it is looped back as a LMR at the far end. When the originator receives the LMR, it can proceed to measure the loss. In both of these methods, the management messages are sent regularly and include counts of the numbers of data packets transmitted and received up to the time the management packet was sent. Frame Loss is calculated by comparing these counter values. Measurement of both ‘near end’ and ‘far end’ frame loss can be made. An SLA threshold called ‘frame loss ratio’ governs the percentage of packets that are permitted to be lost and this is the metric reported.
Frame delay and frame delay variation can be measured in one of two ways also. They can be measured on demand using ‘delay measurement messages’ (DMMs) and ‘delay measurement responses’ (DMRs) in cases where the clocks are not synchronised at each end of the link. The originator sends a DMM, and it is looped back as a DMR at the far end. When the originator receives the DMR, it can proceed to measure the delay and delay variation. Alternatively, if the clocks at each end are synchronised, the originator can send a ‘one way delay message’ (1DM) to the far end, where the delay and delay variation measurements are made. SLA thresholds govern the maximum delay and delay variation values (typically expressed in milliseconds) and this is the metric that is reported.